The present invention generally relates to input/output (I/O) operations in information handling systems, and, more particularly, to full-screen input/output (I/O) operation of a display device in an information handling system, such as a computer system running one or more application programs (software) in conjunction with an operating system (software).
Typically, an information handling system, such as a computer system, includes a central processing unit (CPU) controlled by an operating system (software), and has one or more application programs (software) that perform I/O operations using a display device, such as a terminal with an attached keyboard, through which a user of the computer system can input information (data) to, and receive information (data) from, the computer system. The operating system normally includes a control program (CP) capable of controlling I/O operation of the display device by causing control signals to be provided to the display device as required during normal operation of the computer system. Also, the application program(s) may control I/O operation of the display device by including in their program code appropriate instructions for causing these same kinds of CP control signals to be provided to the display device. However, this requires application programmers to be familiar with relatively low level CP programming techniques and instructions, and presents programming compatibility problems when it is desired to transfer an application program from one computer system to another computer system having a different operating system. Primarily because of the foregoing, application programs have not taken full advantage of the full-screen I/O capabilities of display devices, or have often limited their I/O operation of display devices to line-oriented input and output.
For example, prior to introduction by International Business Machines (IBM) Corporation of the present invention as part of the Conversational Monitor System (CMS) in the IBM Program Product operating system named Virtual Machine/System Product (VM/SP) (IBM Program Product Number 5664-167), support for display devices was limited to line-oriented input and output. In fact, CMS itself did not even make full-screen use of its virtual console (a virtual console is a console simulated by CP on a terminal) except in the System Product Editor (XEDIT), which, though part of CMS, is really an application program that resides in the CMS nucleus for performance reasons. Any other CMS application program which required full use of a display screen had to avail itself, as XEDIT did, of the full-screen console support provided by the VM/SP control program (CP), embodied in a Diagnose X'58' instruction which is a low-level CP instruction to a virtual console, and which is described in more detail in an IBM publication entitled "VM/SP System Facilities for Programming, Release 5" (SC24-5288-0), the entire disclosure of which is incorporated herein by reference. The interface presented by the Diagnose X'58' instruction is equivalent to that of the System/370 Start I/O (SIO) instruction, which is a System/370 assembler programming language instruction, and which is described in more detail in an IBM publication entitled "IBM System/370 Principles of Operation" (GA22-7000), the entire disclosure of which is incorporated herein by reference. Any computer program issuing the Diagnose X'58' instruction must construct channel programs defining the I/O operations to be performed, field I/O interrupts generated either by execution of the channel programs or by user activity at the keyboard, and recover from any errors that may result. Doing this correctly involves delicate and complicated programming, and, if the programming is not done carefully, can result in faulty program code in CMS application programs which do full-screen I/O to a display device.
Although CMS has long had an application interface for fielding I/O interrupts (a macro named HNDINT), it is somewhat difficult, and not particularly practical, for full-screen programs to use HNDINT in managing the virtual console because of the need to share the virtual console with the native CMS line-oriented support. Since the issuer of HNDINT is expected to take complete responsibility for the device being managed, a program using HNDINT for the virtual console has to duplicate all of CMS line-oriented console support as well as implement its own full-screen operations, which can be burdensome. As a result, full-screen CMS programs have been obliged to subvert the defined CMS interface for managing virtual devices. This has commonly been done by altering the instruction address in the I/O new PSW (program status word), so that receipt of an I/O interrupt causes control to transfer into the application program rather than into the CMS nucleus. It then devolves upon the application to pass any interrupts which it cannot handle (for example, for devices other than the console) on to the standard CMS I/O interrupt handler. This additional complexity can lead to additional faulty application program code, particularly when one full-screen program may invoke another, unless the programmer is very careful when writing the application program code.
Even a computer program which does low-level console I/O (as described above) correctly is faced with additional complications if it is required to execute in both System/370 and System/370-Extended Architecture (XA) virtual machines, or on both virtual consoles and dedicated display devices. To exploit the larger address spaces available in System/370-XA, computer programs must be capable of handling 31-bit storage addresses. However, the channel programs used by Diagnose X'58' cannot address storage above 16 megabytes without the use of Indirect Data Address Lists (IDAL's). Also, the I/O instructions that must be used in addition to Diagnose X'58' are completely different in System/370 and System/370-XA, so that a program which has to execute in either environment is obliged to include separate execution paths for each. Similarly, the System/370-XA PSW format is different from that traditionally used by CMS in System/370 mode, leading to additional complexity in stealing the I/O new PSW when both modes must be supported. Furthermore, the Diagnose X'58' interface is only valid for the virtual console. I/O to a dedicated display device must be performed with the System/370 SIO or System/370-XA Start Subchannel (SSCH) instruction, and somewhat different channel programs must be built.
As is apparent from the foregoing, there is a need to provide solutions to the full-screen I/O problems discussed above. For example, there is a need to free application programs from building channel programs, handling I/O interrupts, or worrying about the details of error recovery. In addition, it is desirable in an operating system environment, such as a VM/SP environment, to eliminate the need to subvert CMS I/O interrupt handling by stealing the I/O new PSW. Also, there is a need for defining an interface that is independent of virtual machine architecture and virtual device implementation and which performs equivalently in System/370 or System/370-XA machines and on virtual consoles or dedicated displays. Further, there is a need to provide additional function for coordinating use of a display screen by multiple application programs, as well as coordinating full-screen I/O within an operating system.